障害調査依頼でネットワークの設定を疑った時に確認していること
こんにちは!! 筧( @TakaakiKakei )です。
「EC2 インスタンス自体は正常に稼働しているのに、なぜか接続できない」 という問い合わせを度々いただきます。 今回はネットワークの設定起因という想定で、AWS リソース側で確認したい項目を紹介します！
前提
以下の前提で確認ポイントを紹介します。
- 特定のセグメントから EC2 インスタンスに HTTP 接続したい
- AWS 基盤側には問題が発生していない
- EC2 インスタンス自体は正常に稼働している
確認ポイント
以下のポイントごとに紹介します。
- セキュリティグループ
- ネットワーク ACL
- ルートテーブル
- その他
セキュリティグループ
対象 EC2 インスタンスの説明タブから、設定しているセキュリティグループを開きます。
EC2 と直接通信する時は、インバウンドルール と アウトバウンドルール の設定で、対象の HTTP 通信が許可されているか確認しましょう。
ELB 経由で通信する時は、「 ELB にて対象の HTTP 通信が許可されているこ」、「 EC2 にて ELB との通信が許可されていること」を確認しましょう。
よくある設定例は以下のブログが参考になります。
ネットワーク ACL
対象 EC2 インスタンスの説明タブから、サブネットを開きます。
ネットワーク ACL タブを開きます。
インバウンドルール と アウトバウンドルール の設定で、対象の HTTP 通信が許可されているか確認しましょう。 ネットワーク ACL のよくある設定例も先ほど紹介したブログが参考になります。
設定する機会が少ないかもしれませんが、ネットワーク ACL で HTTP 通信を制限する際の注意点について書いたブログも紹介しておきます。
ルートテーブル
NACL の設定確認時に開いたサブネットの画面からルートテーブルのタブを開きます。 クライアント元によって適切なゲートウェイが設定されていることを確認します。 以下に例を挙げます。
- インターネットからのアクセス：インターネットゲートウェイ(IGW)がアタッチされているか
- オンプレミス環境や社内ネットワークからのアクセス：バーチャルプライベートゲートウェイ(VGW)やカスタマーゲートウェイ(CGW)がアタッチされているか
その他
その他についても網羅的に書きたいところですが、紹介したポイント以外については、使用しているゲートウェイや接続によって大きく異なります。
なので今回、その他については以下の公式ドキュメントを引用させていただきます。経路上で利用しているサービスのトラブルシューティングを参照下さい。
VPC ルートテーブルの問題をトラブルシューティングする方法を教えてください。
最後に
いかがだったでしょうか。その他の内容についても別途ブログ等で詳しく紹介できたらと思ってます。 障害対応シリーズは他にも書いているので良かったら参照下さい！
以上！筧( @TakaakiKakei )でした！
更新履歴
- 2020/03/19 新規作成
